Proposal: Arm64 Support and Multi-Architecture Image Publishing for Harbor #262
Conversation
|
@ranimandepudi bitnami has already built arm images for Harbor, it is open-sourced in https://github.com/bitnami/containers/tree/main/bitnami, and images is available in https://hub.docker.com/r/bitnami/harbor-core, maybe you could reference it. |
Thanks for sharing this @stonezdj ! Just to clarify — the changes I proposed in the PR are focused solely on enabling multi-arch Docker image builds without impacting existing functionality. Since Photon OS already supports both amd64 and arm64, my patch preserves the current behavior while adding support for Arm builds in a clean and upstream-friendly way. |
|
@ranimandepudi can you link the PR in the main repository for the changes! |
|
@ranimandepudi can you please fix your DCO |
ranimandepudi
force-pushed
the
my-new-proposal-arm64
branch
from
14aec1f to
6e1fe36
Compare
Signed-off-by: Rani Chowdary Mandepudi <[email protected]>
ranimandepudi
force-pushed
the
my-new-proposal-arm64
branch
from
6e1fe36 to
a044855
Compare
|
@OrlinVasilev Thank you for your support! I have made the updates based on your comments. Please let me know if any further changes are needed. |
proposals/arm64-support-harbor.md
Outdated
|
|
||
| ## Testing | ||
|
|
||
| To validate that our custom-built Harbor instance with ARM64 support works correctly across components and architectures, I performed the following levels of testing: |
There was a problem hiding this comment.
This should be automatically done in the CI.
There was a problem hiding this comment.
Yes I will update it but just added it is also manually tested !!
| ranichowdary/jobservice-harbor | ||
| ranichowdary/jobservice-base-harbor | ||
| Registry: | ||
| ranichowdary/registry-harbor |
There was a problem hiding this comment.
Let me use the registry build as an example to illustrate the idea. We currently have two Dockerfiles involved in the process—one for building the binary and another for creating the final image.
From my understanding, the first step should be updating the Dockerfile.binary and its corresponding builder scripts to support specifying GOARCH when compiling the registry binary. Once that's in place, we can evaluate whether changes to the second Dockerfile (used for building the final image) are also needed.
RUN CGO_ENABLED=0 GOARCH=$TARGETARCH make PREFIX=/go clean binaries
I believe it's important to include sufficient technical detail here, rather than keeping it high-level. This will help the maintainers better assess whether the proposal is technically sound and practically feasible.
There was a problem hiding this comment.
@wy65701436 While our CI now builds on native amd64 and arm64 runners via a matrix strategy (so cross-compilation isn't strictly required), would you still recommend explicitly adding GOARCH=$TARGETARCH in Dockerfile.binary?
There was a problem hiding this comment.
I think we should have some discussion around this part, as the parameter needs to be passed down from the top-level make call to the lower levels.
A few questions to consider:
How should we structure the code?
Will we maintain separate builders and Dockerfiles for each architecture, or consolidate them into one?
From an engineering perspective, I’d prefer to separate the code paths initially — one for x86 and one for ARM — and merge them later once the ARM path is stable and production-ready. While this approach introduces some code duplication, it ensures that our current stable releases remain unaffected.
|
|
||
| These changes allow Harbor to be built, packaged, and installed cleanly on Arm64 hosts such as AWS Graviton and also on x86 as images are multi arch. | ||
|
|
||
| This proposal introduces native Arm64 builds for Harbor components using `Docker Build` and multi-architecture manifests. Each image is tested and published in a way that maintains compatibility with existing Amd64-based deployments. |
There was a problem hiding this comment.
Since Harbor has already released both offline and online installers to the community, does this proposal also cover the release of Harbor ARM installers (both offline and online)?
I bring this up because if we decide to release the ARM installer, we should also consider the prepare image, as it plays a critical role in the installation process. If this proposal does not cover that scope, please add a section to clarify what is and isn’t included.
There was a problem hiding this comment.
Ok I will update it and commit !!
There was a problem hiding this comment.
Can you provide an update on this? I believe we should support both the online and offline installers, at least in Phase 2. Otherwise, it seems we would only be providing the Harbor Helm chart on ARM — is that aligned with your thinking?
|
|
||
| ## Build and Push Workflow (Per Architecture) | ||
|
|
||
| Each image is built and pushed in the following steps: |
There was a problem hiding this comment.
From the entrypoint perspective, will we add a flag to the Makefile to specify the target platform architecture for building images? I assume we should include such a flag, with x86_64 as the default, and allow it to be extended to support arm as well.
Signed-off-by: Rani Chowdary Mandepudi <[email protected]>
ranimandepudi
force-pushed
the
my-new-proposal-arm64
branch
from
65692f9 to
204bad3
Compare
|
@wy65701436 — Could you please review it and let me know if anything needs to be updated ? I have the CI pipeline changes in my local, can push them once this is tested !! |
Tested and confirmed: Harbor functions fully on both Arm64 and Amd64 platforms, including the UI, API, registry, and multi-architecture artifact handling.
As the author of this contribution from Arm, I welcome any feedback, collaboration, or questions from the Harbor community.
Thank you to the community for your continued support. Arm ambassadors are always ready to support Harbor.
Related PR in the main Harbor repository: goharbor/harbor#21982